fix(moshpit): park names at a URL that exists - #56
Merged
Conversation
An unpointed name was sent to moshcoding.com/parking?name=… — a route that has never existed. That is the Next.js site, not the registry, and it has no such handler. So every claimed-but-unpointed name, and every unclaimed one, 404'd. From a browser that is indistinguishable from the namespace not working: mosh.eggs resolved instantly and showed nothing. Parking now goes to the registry's own /n/<name>, which is also where a *pointed* name is fetched. One route for both, because "what is behind this name" and "there is nothing behind this name yet" are the same question with different answers — and the second answer is a directory of what else lives under that ending, so an unclaimed name becomes a way into the namespace instead of a dead end. Four tests hardcoded the old URL and were updated rather than deleted; the behaviour they cover is unchanged, only the destination. 96 across the desktop suite. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
Merged
ralyodio
added a commit
that referenced
this pull request
Jul 31, 2026
Ships the parking fix (#56): an unpointed name was sent to moshcoding.com/parking, a route that has never existed — that is the Next.js site, not the registry. Every claimed-but-unpointed name and every unclaimed one 404'd, which from a browser is indistinguishable from the namespace not working: mosh.eggs resolved instantly and showed nothing. Parking now goes to the registry's own /n/<name>, the same route that serves a pointed name, which answers with a directory of what else lives under that ending rather than a dead end. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
ralyodio
added a commit
that referenced
this pull request
Jul 31, 2026
) A stored base beats the shipped default — that is what storing one is for — but it makes "I saved settings once" indistinguishable from "I chose this value". An install that ever persisted moshcoding.com as its parking base keeps pointing at a route that has never existed, through every future release, and shipping the right default does nothing about it. #56 fixed the default and could not reach anyone already holding a copy of the old one. Two halves. On read, a stored base that merely repeats a superseded default is treated as absent. Only stale defaults are on that list, so a base someone actually chose is never on it and is never touched. This repairs an affected install with no action from its owner, which matters because nobody knows to go looking. On write, the options page only persists what was filled in. It wrote the whole object, so an empty registry field stored "" — and a stored value, even an empty one, is a decision the read path then has to keep honouring. Leaving a field out is what lets it keep following whatever the default becomes. 100 across the desktop suite. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
An unpointed name was sent to
moshcoding.com/parking?name=…— a route that has never existed. That's the Next.js site, not the registry, and it has no such handler.So every claimed-but-unpointed name, and every unclaimed one, 404'd. From a browser that's indistinguishable from the namespace being broken:
mosh.eggsresolves instantly and shows nothing.The fix
Parking now goes to the registry's own
/n/<name>— which is also where a pointed name is fetched. One route for both, because "what is behind this name" and "there is nothing behind this name yet" are the same question with different answers.The second answer is a directory of what else lives under that ending, so an unclaimed name becomes a way into the namespace instead of a dead end.
A self-hosted parking base still works —
https://my.pit/→https://my.pit/n/a.eggs.Pairs with
moshcoder/moshcode#149, which makes that route answer 200 instead of 404 for a parked name — the body was already right, the status said the URL had nothing at it.
Tests
Changed in both the TS module and its extension port, kept in step by the existing faithfulness test. Four tests hardcoded the old URL and were updated, not deleted — the behaviour they cover is unchanged, only the destination.
96/96 desktop suite.
🤖 Generated with Claude Code